Communication system utilizing http

ABSTRACT

A method of establishing a communication link via a communication system which is operable to support HTTP-based communication is provided. The method includes:
     (a) using the system to establish a two-way real-time communication link between two nodes of the system by employing a combination of GET and POST methods associated with HTTP; and   (b) TCP/IP and/or UDP tunnelling the two-way communication link by employing a CONNECT method associated with HTTP.   

     There is also provided a communication system which is operable to support HTTP-based communication, wherein the communication system is operable to establish a two-way real-time communication link between two nodes of the system by employing a combination of GET and POST methods associated with HTTP, and wherein the two-way communication link is TCP/IP and/or UDP tunnelled by employing a CONNECT method associated with HTTP.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of PCT International PatentApplication No. PCT/EP2014/001052 filed Apr. 21, 2014, which claims thebenefit of UK Patent Application No. 1307340.8, filed on Apr. 23, 2013,the entire disclosure of each of which is incorporated herein byreference.

TECHNICAL FIELD

The present disclosure relates to communication systems, for example tocommunication systems which utilize Real-Time Hypertext TransferProtocol (HTTP) for communicating various types of digital data, forexample graphics data, image data, video data, audio data and similar.Moreover, the present disclosure is also concerned with methods ofoperating aforesaid communication systems for communicating varioustypes of data. Furthermore, the present disclosure is also concernedwith software products recorded on machine-readable data storage media,wherein the software products are executable upon computing hardware forimplementing aforesaid methods.

BACKGROUND INFORMATION

In overview, Hypertext Transfer Protocol (HTTP) is widely used forimplementing the contemporary Internet. The Protocol is an applicationprotocol for distributed, collaborative hypermedia information systems.In implementation, HTTP is a multi-linear set of objects which areoperable to build a network using logical links to define the network;the links are often referred to as being “hyperlinks” which define anetwork relationship between nodes.

HTTP is operable to function as a request-response protocol, for examplein a client-serving model as implemented for the Internet. In the model,a web browser is optionally used to implement a client, and a softwareapplication executing upon a server may host a web site. In operation, agiven client submits a HTTP request message to the server, whichresponds by providing resources such as HTML files and other content, orperforms data processing functions on behalf of the client, or evenreturns a response message to the client. The aforesaid web browser issusceptible to being implemented in various ways, for example as a useragent, as a web crawler or any other software executable upon computinghardware that accesses, consumes or displays Internet-derived datacontent.

HTTP is designed to permit immediate network elements to enablecommunications between clients and servers. High-traffic web-sites ofthe Internet often employ web cache servers that are operable to delivercontent on behalf of upstream servers to improve response times for dataand/or service delivery. Moreover, HTTP proxy servers at private networkboundaries are beneficially used to facilitate communication for clientswithout a globally routable Internet address, namely by relayingmessages via external servers.

HTTP resources are identified and located on a given network by usingUniform Resource Identifiers (URI's), also referred to as UniformResource Locators (URL's). Moreover, URI's and hyperlinks are expressedin Hypertext Markup Language (HTML) that is capable of forming webs ofmutually interlinked hypertext documents.

An HTTP session is implemented by way of a sequence of networkrequest-response transactions. For example, an HTTP client initiates arequest by establishing a Transmission Control Protocol (TCP) connectionto a particular port on a server. An HTTP server listens for theclient's request message and responds by sending back a status line, forexample “HTTP/1.1 200 OK” together with an associated message. A body ofthis associated message is often the requested resource, although anerror message may alternatively be returned.

HTTP defines methods, conveniently referred to as “verbs”, forindicating a desired action to be performed in respect of an identifiedresource. The resource is, for example, a data file or an output from anexecutable object residing on one or more servers. Examples of HTTPmethods, also known as HTTP “verbs”, are provided in Table 1.

TABLE 1 HTTP methods (HTTP “verbs”) “Verb” Details GET Requests arepresentation of a specified resource, wherein requests using “GET”should only retrieve data HEAD Requests a response which is identical tothat obtainable from GET, but devoid of any response body; “HEAD” isoften employed for retrieving meta-data in an efficient manner POSTRequests that a given server accepts an entity enclosed in the requestas a new sub-ordinate of a given web resource identified by a URL PUTRequests that an enclosed entity be stored in respect of a supplied URI(URL). If the URI refers to an already existing resource, that resourceis modified. DE- Requests deletion of a specified resource LETE TRACEResults in a received request to be echoed back to the given client OP-Returns HTTP methods supported by a server associated with a TIONS givenURL CON- Converts a requested connection to a transparent TCP/IP tunnel,NECT for example for facilitating TLS and SSL-encrypted communication(HTTPs) through an unencrypted HTTP proxy as aforementioned; by default,an HTTP connection is unencrypted, whereas an HTTPS connection isencrypted. PATCH Requests application of partial modifications to agiven resource

Thus, a principal transfer protocol employed by contemporary webbrowsers is aforesaid HTTP; several associated “ecosystems”, andsoftware that they utilize, in particular browser software applications,are not able to function without using

HTTP. As aforementioned, HTTP is based upon requests, see Table 1, thatare transmitted and, on response to these requests, HTML pages or binarydata such as images or audio streams/files are commonly served inresponse to receiving the requests.

On account of the complexity of the Internet, Internet communicationdelays, namely “latency”, can arise in operation. Such delays can causeproblems in demanding data exchange situations, for example when two-way(full-duplex) communication is desired, where real-time response isdesired, for example transfer and reception of video images and/or audiowith very little delay. Bi-directional communication via the Internet isknown from Voice-over-Internet-Protocol (VoIP) and also fromInternet-based video conferencing, for example as contemporarilyprovided using Skype software and similar; “Skype” is a registeredtrademark.

It is known to employ protocols known as “WebSockets”, as described at aweb-site http://tools.ietf.org/html/rfc6455, for addressing specifictypes of communication needs. Following communication properties arethereby capable of being achieved:

-   -   (i) a WebSocket is employed inside an HTTP/HTTPS tunnel; in such        a case, firewalls have already been opened for ports 80/443,        because they are contemporarily commonly utilized on web        browsers; and    -   (ii) a WebSocket is utilized in a full-duplex connection mode,        wherein only one TCP connection is able to communicate both ways        in real-time, namely it is able to transmit and receive data        with one connection by changing the direction of data delivery.

However, such WebSockets can be port-dependent which represents anundesirable limitation.

SUMMARY

The present disclosure seeks to provide a communication system which iscapable of providing two-way data communication via an HTTPcommunication network in an improved manner.

Moreover, the present disclosure seeks to provide an improved method ofoperating a communication system for providing two-way datacommunication via an HTTP communication network.

According to a first aspect of the present invention, there is provideda communication system which is operable to support HTTP-basedcommunication, wherein the communication system is operable to establisha two-way real-time communication link between two nodes of the systemby employing a combination of GET and POST methods associated with HTTP,and wherein data exchange via the communication link is implemented in achunked manner and/or as a series of multipart data blocks, wherein amaximum segment size (MSS) for data chunks and/or multipart data blockscommunicated through the communication link is optimized as a functionof a communication network capability supporting the communication link.

The communication system is of advantage in that it is capable ofproviding real-time two-way communication with reduced latency.

Optionally, the CONNECT method is capable of being used in threedifferent types of scenario:

-   -   (i) a connection is tunneled into a target; this is beneficially        a default scenario;    -   (ii) a connection is tunneled via a local host to a target,        resulting in data being transferred from a transmission process        in the local service to a forwarding proxy process, from within        the data is transmitted to the target; such an approach is        beneficial because it is capable of preventing anti-virus        software from analyzing the data and inadvertently blocking or        otherwise interfering with the data;    -   (iii) a connection is tunneled into a forwarding proxy server        which then redirects the data to its target; such an approach is        beneficial to employ in load-balancing systems, namely in        systems wherein a network load caused by clients is distributed        optimally to the target. For example, it is faster to transmit        data in a backbone network than via direct connection.

Optionally, in the communication system, the communication link includesa reception connection and a transmission connection for providing thetwo-way communication, and wherein the connections are maintained openuntil an empty chunk and/or an empty multipart data block is received.

Optionally, in the communication system, the communication link isoperable to employ encryption of data communicated therethrough.

Optionally, in the communication system, the communication link isoperable to provide communication of at least one of: graphics data,image data, video data, audio data, unstructured data.

According to a second aspect of the disclosure, there is provided amethod of establishing a communication link via a communication systemwhich is operable to support HTTP-based communication, wherein themethod includes:

-   -   (a) using the communication system to establish a two-way        real-time communication link between two nodes of the system by        employing a combination of GET and POST methods associated with        HTTP;    -   (b) exchanging data via the communication link in a chunked        manner and/or as a series of multipart data blocks; and    -   (c) optimizing a maximum segment size (MSS) for data chunks        and/or multipart data blocks communicated through the        communication link as a function of a communication network        capability supporting the communication link.

Optionally, in the method, the communication link includes a receptionconnection and a transmission connection for providing the two-waycommunication, and wherein the connections are maintained open until anempty chunk and/or an empty multipart data block is received.

Optionally, in the method, the communication link is operable to employencryption of data communicated therethrough.

Optionally, in the method, the communication link is operable to providecommunication of at least one of: graphics data, image data, video data,audio data, unstructured data.

According to a third aspect of the disclosure, there is providednon-transitory computer-readable storage medium for establishing acommunication link via a communication system which is operable tosupport HTTP-based communication, comprising computer program code whichwhen executed by a data processing system, causes the data-processingsystem to:

-   -   (a) use the system to establish a two-way real-time        communication link between two nodes of the system by employing        a combination of GET and POST methods associated with HTTP;    -   (b) exchange data via the communication link in a chunked manner        and/or as a series of multipart data blocks; and    -   (c) optimize a maximum segment size (MSS) for data chunks and/or        multipart data blocks communicated through the communication        link as a function of a communication network capability        supporting the communication link.

Optionally, the computer program code is expressed in HTTP and isexecutable upon a server of a communication network operating accordingto HTTP.

The present invention is of advantage in that the communication systemis capable of providing two-way, full-duplex communication, eitherunencrypted or encrypted, by utilizing known HTTP transfer protocol insuch a way that extra configurations are not necessary in software orhardware firewalls and/or in anti-virus software applications executingin the communication system.

Moreover, the present invention is of advantage in that it improves thefunctionality and reliability of communication applications, and thussimplifies technical maintenance issues associated with the system, forexample data security settings.

It will be appreciated that features of the invention are susceptible tobeing combined in various combinations without departing from the scopeof the invention as defined by the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present disclosure will now be described, by way ofexample only, with reference to the following diagrams wherein:

FIG. 1 is an illustration of a communication network operable to employHTTP;

FIG. 2 is an illustration of a set of steps of a method of thedisclosure; and

FIG. 3 is an illustration of an alternative set of steps of a method ofthe disclosure.

In the accompanying diagrams, an underlined number is employed torepresent an item over which the underlined number is positioned or anitem to which the underlined number is adjacent. A non-underlined numberrelates to an item identified by a line linking the non-underlinednumber to the item. When a number is non-underlined and accompanied byan associated arrow, the non-underlined number is used to identify ageneral item at which the arrow is pointing.

DETAILED DESCRIPTION

In overview, with reference to FIG. 1, there is hereinafter described asystem, a portion of which is indicated generally by 5, and associatedmethod, which is capable of deducing delays, namely “latency”, inrespect of HTTP for two-way real-time communication in a manner thatdescription of HTTP employed conforms to standards such as RFC2621,RFC2068 and RFC1945. Normally, HTTP is not designed to enable real-timetwo-way communication between first and second nodes 10A, 10B, wherein agiven client is able simultaneously to transmit real-time data and toreceive real-time in such a manner that:

-   -   (i) a communication connection 20 employed between the two nodes        10A, 10B is operable to support the two-way communication in an        encrypted format;    -   (ii) virus protection software 30 does not interfere with        contents 40 being transmitted and received via the communication        connection 20;    -   (iii) firewalls 60 are not able to prevent network traffic        unless a general blockage of Internet traffic, namely “WWW        traffic”, is blocked, for example in a situation of a banking        connection employed for secure financial transactions; and    -   (iv) network devices, for example bridges and routers, are not        able to analyze and interfere with data to be communicated via        the communication connection 20.

Embodiments of the present disclosure are capable of addressingfunctionalities (i) to (iv) by employing the following features:

-   -   (a) two mutually different types of GET and POST methods are        used, see Table 1 above, wherein the GET method constructs a        reception connection via the communication connection 20, and        the POST method constructs a transmission connection via the        communication connection 20;    -   (b) both connections are tunnelled using the CONNECT method as        employed in contemporary HTTP; and    -   (c) a form of “chunked” or multipart transfer encoding is        employed, as will be elucidated in more detail below.

Conventionally, HTTP is used for Internet sessions, wherein the GET andPOST methods are employed in a mutually independent manner. For example,the GET method is used for requesting HTML content from a web-serverwhich is operable to function as a host for a web-browser client,wherein connections for the GET method remain open until all responsedata is delivered from the host to the client. Moreover, a connectionprocedure is employed which is the same as the POST method, see Table 1,except that data is delivered from the client to the host.

It will be appreciated that the connection can be initialised both withthe GET method and with the POST method. It is not relevant for themethod pursuant to the disclosure which method is used to open theconnection.

In embodiments described hereinafter, communication is executed in sucha manner that a given socket is used in a half-duplex manner, whichdistinguishes the embodiments from known approaches, for exampleaforesaid WebSockets. In the embodiments, transmission and/or receptionof data is more efficient than in a full-duplex connection, becausenetwork interface cards do not need to switch their input/output (I/O)states between reception and transmission. Such switching employed inknown technical art consumes system resources and correspondinglydecreases potential communication speed. The embodiments pursuant tothis disclosure comply entirely with the HTTP standard, and do not tryto lure the server to forcefully keep open, but instead comply fullywith the definition of transfer encoding in the HTTP standard, thusyielding improved communication performance.

In the embodiments described hereinafter, a socket is utilized after aninitialisation of HTTP GET and POST methods only, either in a receptionmode or in a transmission mode. In consequence, a network adapter usedonly needs to operate in a half-duplex state only, thereby savingnetwork infrastructure and device resources, because the connectionoperates solely in either a transmitting mode or a reception mode afternegotiated HTTP GET and/or POST method headers until a finish of theconnection occurs. Moreover, other benefits also arise, for examplefirewalls and routers, namely hubs and switches, receive less switchingload and thus will not break as fast as known contemporary full-duplexcommunication approaches that use only one full-duplex connection. Thus,embodiments described hereinafter are much more resource-efficient thanaforesaid WebSockets, for example.

Aforementioned known WebSockets can easily be analysed by firewalls asbelonging to an unidentified connection type and thus be disconnected,thereby preventing or restricting their usage, irrespective of whetheror not an associated connection is tunnelled or not. In embodimentsdescribed hereinafter, a GET or POST connection functions according tothe HTTP protocol, and thus firewalls cannot restrict or preventcommunication utilizing these methods. For this purpose, the systempursuant to this disclosure optionally also utilize the tunnelledconnection.

In the embodiments as described hereinafter, UDP protocol which isestimated to be substantially three times faster than TCP, isbeneficially employed. Optionally, the embodiments can use peer-to-peer(P2P) connections, which allow communication to be achieved atapplication level.

Embodiments described herewith are differentiated from known HTTPimplementations, in that known HTTP implementations are devoid of anylink between GET and POST methods; in contradistinction, embodimentsdescribed herein employ GET and POST methods merged together in a novelmanner for providing a real-time full-duplex data communication. Thementioned full-duplex data communication is implemented by using onereception connection and one transmission connection. One receptionconnection or one transmission connection can use one half-duplexconnection mode or one full-duplex connection mode.

Although embodiments will be described below based upon TransportControl Protocol (TCP), it will be appreciated that User DatagramProtocol (UDP) can be employed as an alternative. Although both the UDPand TCP rely on an underlying Internet Protocol (IP), and both a UDPdatagram and a TCP segment are transmitted in an IP packet, the UDP isdistinguished in that it is a connectionless protocol that makes itpossible to achieve peer-to-peer communications between applications,not only inside a local area network (LAN), but also in the outerInternet, by using a network address translation (NAT) traversaltechnique. By employing such an approach, a need to transfer data viaservers in the system 5 can be avoided, resulting in considerablecommunication network capacity being saved. An additional benefitresulting from using UDP in the system 5 is that it is substantiallythree times more efficient in its use of network communication capacitythan TCP, because UDP is not a controlled protocol. Moreover, the MSScapacity measured in bytes in both IPv4 and IPv6 communication networks,for example used for implementing the system 5, is larger, because UDPheaders are smaller than corresponding TCP headers.

Although use of TCP for both GET and POST connections will be describedin the following, it will be appreciated that, optionally, only one ofthese connections uses TCP and the other of these connections uses UDP.Moreover, it will also be appreciated that both the GET and POSTconnections can utilize UDP.

It will be appreciated that the data in the transmitting or receivingend can also change from the circuit switched to IP-based data andcorrespondingly from IP-based to circuit switched data, withoutdeparting from the scope of the invention.

In a first example embodiment, a series of steps are performed asfollows with reference to FIG. 2:

STEP 1 (S1): a client to a data connection generates a unique streamidentification (ID), wherein the ID is employed to pair GET and POSTmethods together, so that a server employed to implement the dataconnection is aware that the pair of GET and POST methods belong to thesame client. The ID employed will be elucidated in greater detail later.However, it will be appreciated that GET and POST methods do not limitthe present invention when the unique stream identification (ID) is usedto combine transmission and reception connections. The principal purposeof the Stream ID is to bind the transmission and reception connectionsof the client together at the server. This means that the server canthen discard harmful, erroneous and/or unidentified connections beforetheir processing continues. Such functionality makes it possible toprotect the server and to reduce/prune the server load caused byunidentified connection requests and unnecessary computing. In otherwords, this enables the system to conserve resources, which provides abenefit of saving energy and decreasing the number of servers that areneeded in the server facilities, especially in load balancing systems.

STEP 2 (S2): the client then establishes two TCP/IP connections to theserver, for example at its default port “80”, after which the clienttransmits a header associated with a CONNECT method. In operation, theCONNECT method converts the requested data connection into a transparentTCP/IP tunnel, for example usually to facilitate TLS and SSL-encryptedcommunication (HTTP) through an unencrypted proxy as aforementioned.

When implementing the STEPS 1 and 2, various forms of encryption areoptionally employed, for example SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS1.1, TLS 1.2 or similar types of encryption. However, the aforesaidtunnel is beneficially transparent for ensuring secure communicationbetween different “ecosystems”. Moreover, it is also beneficial toemploy hardware which is protected against malicious attacks orinterference. Such a transparent tunnel connection as employed forimplementing embodiments of the disclosure is capable of preventinghacker, hostile software, anti-virus software, firewall software orother devices and/or software that are operable to monitor and analyzedata traffic from interfering with data that is communicated via thetunnel connection.

STEP 3 (S3): depending upon the receiving or transmitting connectionemployed for the communication tunnel, the header of the GET method orthe POST method continues to be transmitted and received. The headercontains necessary information for a given communication sessionprovided by the communication tunnel. Moreover, the header beneficiallyemploys a convention form of data structure, although the headerincludes following parameters:

-   -   (i) the stream ID kind of information for bonded/linked        connections; and    -   (ii) the transfer encoding as chunked or multipart format.

Optionally, the header can contain information related to authenticationof the sender and/or recipient. Alternatively, this information can beprovided in the GET or POST URL.

Information included in the header ensures that transfer and receptionof data occurs as individual data blocks. Beneficially, a MaximumSegment Size (MSS) of the data is optimized to a capability of a networksupporting the communication tunnel, taking into consideration an amountof bytes used for the chunked or multipart header, so that bytes are notlost when transferring and receiving data; a reliable and secure dataexchange is thereby provided.

Such network optimization is, for example, implemented by requesting aMaximum Transfer Unit (MTU) value from networks coupling connectedclient devices to the server. It is thereby feasible to identify aweakest communication link in the communication network, and thereaftersetting the Maximum Segment Size (MSS) for transmissions to a clientdevice associated with the weakest link at a rate which can beaccommodated by the weakest link. The MSS value is optionallycommunicated by the server to other client devices of the system. Suchnetwork optimization is beneficially implemented using a method havingfollowing steps:

Step A: the system determines a weakest data link coupling the server tothe client devices; for example, the MTU value for a given data link is1500 Bytes. When this MTU value is subtracted by the number of TCPheader Bytes, namely 40 Bytes, 1460 Bytes are available. These 1460Bytes correspond to the MSS.

Step B: the system determines a MSS for a given session by employing theMSS of the weakest identified link.

Step C: optionally, a Nagle algorithm employed in the system is disabledin order to prevent congestion control within the system, namelyachieved by setting the TCP_NODELAY option on a socket of the system,which disables the Nagle algorithm. Such disablement of the Naglealgorithm is desirable, because the Nagle algorithm waits before acertain amount of Bytes of data have been added to a transmission queuebefore a corresponding data packet is sent. When the Nagle algorithm isdisabled, the system is capable of sending a data packet of sizedetermined solely by the system, as aforementioned.

STEP 4 (S4): once the HTTP request header has been transmitted, and acorresponding successful response has been received from the server,duplex data reception and transmission are then commenced. There hasthereby been successfully made two connections with the server, namely areception connection and a transmission connection; these connectionsare maintained in an open state until an empty data chunk or an emptymultipart data block is received.

Two example embodiments will next be elucidated by way of HTTP code.

Example 1: there is provided HTTP code which is operable when executedto create a simple tunnelled reception connection between the client andthe server, wherein a peer with an IP address 192.168.0.101 connects toa host with an IP address 192.168.0.100. Use of both “GET” and “CONNECT”methods in the HTTP code is to be found, together with chunkedtransfer-coding being specified:

<connect> <send> CONNECT 192.168.0.100:80 HTTP/1.0 \r\n <send>Mozilla/5.0 (Windows NT 5.0) Gurulogic \r\n <send> \r\n <send> GET/readstream? streamid=12345&param1=value1&param2=value2 HTTP/1.1 \r\n<send> Host: 192.168.0.100 \r\n <send> Transfer-Coding: chunked \r\n<send> User-Agent : Mozilla/5.0 (Windows NT 5.0) Gurulogic \r\n <send>\r\n <recv> HTTP/1.1 200 OK \r\n <recv> 5AD\r\n <recv> 1453 bytes ofdata... \r\n <recv> 5AD\r\n <recv> 1453 bytes of data... \r\n ... <recv>5AD\r\n <recv> 1453 bytes of data... \r\n <recv> 0 \r\n <disconnect from192.168.0.100>

Example 2: there is provided HTTP code which is operable when executedto create a simple tunnelled transmission connection between the clientand the server, wherein a peer with an IP address 192.168.0.101 isconnected with the host that has a corresponding IP address192.168.0.100. Use of both “POST” and “CONNECT” methods in the HTTP codeis to be found, together with chunked transfer-coding being specified:

<connect to 192.168.0.100>  <send> CONNECT 192.168.0.100:80 HTTP/1.0\r\n <send> Mozilla/5.0 (Windows NT 5.0) Gurulogic \r\n <send> \r\n<send> POST /writestream?streamid=12345&param1=value1&param2=value2HTTP/1.1 \r\n <send>Host: 192.168.0.100 \r\n <send> Transfer-Coding:chunked \r\n <send> User-Agent : Mozilla/5.0 (Windows NT 5.0) Gurulogic\r\n <send> \r\n  <send> 5AD\r\n <send> 1453 bytes of data... \r\n<send> 5AD\r\n <send> 1453 bytes of data... \r\n  ... <send> 5AD\r\n<send> 1453 bytes of data... \r\n  <send> 0 \r\n  <recv> HTTP/1.1 200 OK\r\n

In these two Examples 1 and 2, it is assumed that the MSS is 1460 bytes,so actually the data size for an optimized chunk is 1453 bytes. Anoptimized chunk size is calculated in the system by using a formula asgiven in Equation 1 (Eq. 1):

MSS=(beginning of chuck header)−(end of chunk header)   Eq. 1

The beginning of the chunk header consists of the length of the actualchunk data, for example in hexadecimal notation, and of the end of oneor more line characters, which are usually both Carriage Return (CR) andLine Feed (Lf). The end of the chunk is similar to the end of linecharacters, which complete the chunk.

Referring next to FIG. 2, it will be appreciated that the STEP 3 (S3),namely establishing a connection tunnel by utilizing the CONNECT method,is optionally omitted as provided in FIG. 3. The connection tunnel isomitted when there is not a requirement for the tunnel. Thus, when acommunication is not utilized, only STEPS 1, 2 and 4 are employed.Moreover, in respect of FIG. 2, it is also to be appreciated that theconnection tunnel can be constructed only for the GET connection or thePOST connection, namely an asymmetrical tunnel communication arrangementbetween a plurality of nodes; optionally, the communication tunnel isused only for GET or POST connections.

Example 3: MSS optimization depends solely upon a given payload providedby a given data chunk, because corresponding http chunk headers havealready been stripped off at that point in the processing, whereas thepayload of the data block is 100%. Now, such MSS optimization isprincipally based upon a concept as follows: The maximum transmissionunit (MTU) is an individual transmission burst and, as such, the largestprotocol data unit that the layer can pass onwards, for example 1500Bytes, and the MSS (maximum segment size) has a data size which is equalto MTU minus the protocol headers. In the embodiments of the technologypursuant to the present disclosure, the MSS carries exactly the amountof data in Bytes that the weakest link of the network in question cantransmit. Therefore, no splitting of data into smaller packets occurswhen technology pursuant to the application is used, which increases thespeed and reliability of data transmission, which in turn results inless collisions and packet losses, for example in a WiFi network.

An example of MSS optimization is as follows:

OPERATORS between CLIENT 1 CLIENT1 and CLIENT 2 CLIENT 2 (MTU of thenetwork (MTU of the weakest (MTU of the network 1500 Bytes) network 600Bytes) 1300 Bytes)

Commencing Connection Creation:

ICMP-pings are sent to test the network; it is detected thatcommunication between the CLIENT 1 and the CLIENT 2 is prevented ifMTU>600. Therefore, the MTU is set to 600 Bytes, which means that theMSS is 560 Bytes, after the 40 Bytes of TCP header have been omitted,namely taken into account. It will be appreciated that the headers inthe UDP protocol are smaller, so if UDP is used, the payload will becorrespondingly larger.

CLIENT1 then transmits to CLIENT 2 a 3000-Byte packet which is splitinto 6 parts. Such splitting is simple, and beneficially implementedpursuant to a following formula: the entire amount of Bytes is dividedby the smallest MTU in the network, minus the start and end chunkedheaders, namely 3000/(560−(5+2))=5.42 packets, which is rounded to anearest integer number of packets, unless other data is being queued fortransmission.

Packet 1: 560 Bytes are transmitted, of which the payload is 553 Bytes.

Packet 2: 560 Bytes are transmitted, of which the payload is 553 Bytes.

Packet 3: 560 Bytes are transmitted, of which the payload is 553 Bytes.

Packet 4: 560 Bytes are transmitted, of which the payload is 553 Bytes.

Packet 5: 560 Bytes are transmitted, of which the payload is 553 Bytes.

Packet 6: 560 Bytes are transmitted, of which the payload is 235 Bytes.

If the packet were transmitted directly without splitting, namely as one3000 Byte packet, then it would have been divided, namely fragmented, bydevices of operators along the network, which would have taken time andwhich might potentially have caused problems, and possibly it would havebeen necessary to retransmit lost packets, all of which would haveresulted in the transmitter having to wait before transmitting newpackets, due to a lag caused by an unstable network of the recipient.

Modifications to embodiments described in the foregoing are possiblewithout departing from the scope of the invention as defined by theaccompanying claims. Expressions such as “including”, “comprising”,“incorporating”, “consisting of”, “have”, “is” used to describe andclaim the present invention are intended to be construed in anon-exclusive manner, namely allowing for items, components or elementsnot explicitly described also to be present. Reference to the singularis also to be construed to relate to the plural.

1. A communication system which is operable to support HTTP-basedcommunication, wherein the communication system is operable to establisha two-way real-time communication link between two nodes of the systemby employing a combination of GET and POST methods associated with HTTP,and wherein data exchange via the communication link is implemented in achunked manner and/or as a series of multipart data blocks, wherein amaximum segment size (MSS) for data chunks and/or multipart data blockscommunicated through the communication link is optimized as a functionof a communication network capability supporting the communication link.2. The communication system as claimed in claim 1, wherein the two-waycommunication link is TCP/IP and/or UDP tunnelled by employing a CONNECTmethod associated with HTTP.
 3. The communication system as claimed inclaim 1, wherein the communication link comprises a reception connectionand a transmission connection for providing the two-way communication,and wherein the connections are maintained open until an empty chunkand/or an empty multipart data block is received.
 4. The communicationsystem as claimed in claim 1, wherein the communication link is operableto employ encryption of data communicated therethrough.
 5. Thecommunication system as claimed in claim 1, wherein the communicationlink is operable to provide communication of at least one of: graphicsdata, image data, video data, audio data, text data, unstructured data.6. A method of establishing a communication link via a communicationsystem which is operable to support HTTP-based communication, whereinthe method comprises: (a) using the communication system to establish atwo-way real-time communication link between two nodes of the system byemploying a combination of GET and POST methods associated with HTTP;(b) exchanging data via the communication link in a chunked mannerand/or as a series of multipart data blocks; and (c) optimizing amaximum segment size (MSS) for data chunks and/or multipart data blockscommunicated through the communication link as a function of acommunication network capability supporting the communication link. 7.The method as claimed in claim 6, wherein the method comprises TCP/IPand/or UDP tunnelling the two-way communication link by employing aCONNECT method associated with HTTP.
 8. The method as claimed in claim6, wherein the communication link comprises a reception connection and atransmission connection for providing the two-way communication, andwherein the connections are maintained open until an empty chunk and/oran empty multi-part data block is received.
 9. The method as claimed inclaim 6, wherein the communication link is operable to employ encryptionof data communicated therethrough.
 10. The method as claimed in claim 6,wherein the communication link is operable to provide communication ofat least one of: graphics data, image data, video data, audio data, textdata, unstructured data.
 11. A non-transitory computer-readable storagemedium for establishing a communication link via a communication systemwhich is operable to support HTTP-based communication, comprisingcomputer program code which when executed by a data processing system,causes the data-processing system to: (a) use the system to establish atwo-way real-time communication link between two nodes of the system byemploying a combination of GET and POST methods associated with HTTP;(b) exchange data via the communication link in a chunked manner and/oras a series of multipart data blocks; and (c) optimize a maximum segmentsize (MSS) for data chunks and/or multipart data blocks communicatedthrough the communication link as a function of a communication networkcapability supporting the communication link.
 12. The non-transitorycomputer-readable storage medium as claimed in claim 11, wherein thecomputer program code is expressed in HTTP and is executable upon aserver of a communication network operating according to HTTP.